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ABSTRACT 


This thesis investigates the feasibility of software 
safety analysis using Petri net modeling and an automated 
suite of Petri Net UTilities (P-NUT) developed at UC Irvine. 
We briefly introduce software safety concepts, Petri nets, 
reachability theory, and the use of P-NUT. We then develop a 
methodology to combine these ideas for efficient and 
effective preliminary safety analysis of a real-time, 


embedded software, military system. 
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iG INTRODUCTION 


Computers are increasingly being used as passive 
MieMmttoerinagj and active (Controlling) components of real- 


time systems, e.g., air traffic control, aerospace, 
Paeecratco = Industmael “plants and hospital patient 
monitoring systems. The problems of safety become 


important when these applications include systems where the 
consequences of failure are serious and may involve grave 
danger to human life and property. [Leveson and Stolzy, 
moo / | 

Unfortunately, little is known about applying safety 
considerations to the design and evaluation of computer- 
controlled real-time systems. The military relies heavily on 
safety-critical, computer-controlled, real-time systems and 
has published several standards for test and verification of 
Mreware SyStem Safety (MIL-STD-SNS, MIL-STD-882B, MIL-STD- 
1574A). MIL-STD-882B(DoD) contains requirements for software 
hazard analysis and software safety verification, while MIL- 
STD-1574A (USAF) lists the requirements for software safety 
analysis and integrated system (hardware, software, and 
interfaces) safety. MIL-STD-SNS(USN) covers software safety 
analysis for nuclear weapons systems. 

Problems with ascertaining and verifying the safety of a 
software-controlled system include the difficulty of 
providing realistic test conditions and simulating hardware 
errors, transient faults, and system interfaces. There is no 


existing language which incorporates the myriad system 


facets, such as software, hardware, and the resulting 


interfaces. This overall system view is critical, as ene 
greatest source of problems encountered in computer 
controlled systems may be the lack of system level methods. 
(Leveson, 1986] 

There are several proposed techniques for software safety 
analysis, including Petri net modeling [Leveson and Stolzy, 
1987], Fault Tree Analysis [Vesely et al., 1981], and Real- 
Time Logic (RTL) [Jahanian and Mock) toca This thesae 
follows the Leveson and Stolzy use of Petri Net modeling and 
the other techniques will not be discussed further. For a 
brief synopsis on the other methods, see Hayward [1987]. 

The system under investigation is a proposed air-to-air 
guided missile safety and arming device, developed at the 
Naval Weapons Center in China Lake, California. Although 
this particular safety arming device was never actually 
constructed, a software prototype was written and tested. 
This device is excellent for developing a methodology to 
analyze safety-critical computer/software-controlled systems. 
The device is nontrivial, contains embedded software, and if 
designed incorrectly or tested ineffectively might result in 
personal injury or unwanted property Gest rucmien: 

This thesis refines and continues the work of Duston 
Hayward [1987], who initially investigated the practical 
feasibility of using Petri nets, and the Leveson and Stolzy 


[1987] analysis techniques to meet military standards. 


Beginning with the safety and arming device software 
assembler code, and verbal descriptions of the components, 
Hayward [1987] constructed system and system software 
flowcharts and Petri net models of system components. He 
then combined the flowcharts into a single system description 
by conversion to a Petri net model. Using the safety and 
arming device, Hayward demonstrated techniques for manual 
construction of partial reachability graphs and application 
of Leveson and Stolzy [1987] safety analysis methods. 

Following publication of Hayward [1987], the U. S. Naval 
Postgraduate School received a set of automated Petri net 
analysis and utility tools from the Department of Information 
amomecOMmputer Science, University of California, Irvine 
Miergan and Razouk, 1985; Razouk, 1987; Morgan, 1987]. These 
utilities construct the reachability graph of an entered net 
and support automated reachability analysis through use of a 
sophisticated reachability graph analyzer. Our work is the 
first known application of these automated utilities to the 
area of software safety analysis. 

We begin with brief introductions to software safety, 
Petri nets, reachability theory, and use of the Petri Net 
Mieelitaies (P-NUT). We discuss refinements made to the 
Hayward [1987] model and develop a methodology for efficient 
and effective preliminary safety analysis of a complex, 


Bemetey-Critical, software-controlled system. 


bi He INTRODUCTION TO SOFTWARE SAFETY 


A. WHAT IS SOFTWARE SAFETY? 

The American College Dictionary defines safety as the 
quality of insuring against hurt, injury, dangeryeor saaee 
It follows that software safety may be considered as freedom 
from software causing danger or risk. Software, however, is 
inherently safe, Since alone it can do no physical damage. 
Although it is the hardware that the software controls which 
actually presents the hazard, we must treat software and 
hardware as one entity for analysis purposes. “Software 
engineering techniques that do not consider the system as a 
whole, including the interactions between the hardware, 
software, and human operators, will have limited usefulness 
for real-time control software.” [{Leveson, 1986] The safety 
of a software-controlled system is commonly referred to as 
software safety. 

Safety should not be confused with reliability. Safety 
is the probability that a mishap (accident) will not occur 
regardless of whether or not the intended function is 
Pertormed. Reliability is normally defined, in the 
engineering community, as the probability that the system 
will accomplish its intended function for a specified time 
under specified environmental conditions [Ericson, 1981; 


Konakovsky, 1978; Leveson, 1986]. These are quite different 


concepts, as demonstrated in the analysis of munitions. One 
would expect that when the reliability of a weapon is 
improved, the weapon becomes less safe. Improvements that 
increase the probability of detonation may very well increase 
Mme likelihood of accidental firing, unless specific 
precautions are made in the design to improve the safety as 
reliability is improved. [Romana “ane Mowiwamaty, 61983; 


Leveson, 1986] 


B. INTRODUCTION TO SOFTWARE SAFETY ANALYSIS 

To ensure system safety, it is necessary to show that the 
software and hardware will perform as required and verify 
that the relationships between software, hardware, and system 
behavior are correct. 

Many of the system safety techniques that have been 
developed to aid in building electromechanical systems with 
minimal risk do not seem to apply when computers are 
introduced. The major differences appear to stem from the 
lack of system-level approaches to building software 
controlled systems. [Leveson 1986] 

Current system safety techniques do not consider human 
design errors in system failures. Human errors are assumed 
never to have occurred or to have been removed prior to 
Selivery and operation. With the growth of embedded software 
systems and powerful microprocessors, the complexity of 


software and hardware has grown tremendously and resulted in 


a nonlinear increase in human error design flaws. Due to 


system complexity, it may be impossible to prove correctness 
and safety of a realistic control system. [Lauber, 1980] 

Based on this situation, Leveson [1986] argued the need 
for a new approach to the software safety analysis problem. 
The “black box” approach to software is not valid.” A Goma 
system concept must be employed to properly account for 
software effects on the system. 

The initial stage of the analysis is to focus on system 
failures that have the most drastic consequences. This is 
especially useful in situations where the system under 
investigation has relatively few failures leading to mishaps. 
The technique is to start with a given set of unacceptable 
failures and then by means of a “backward” approach ensure 
that the failures are eliminated, or at least minimized. 
[Leveson, 1986] 

One method for combining software, hardware, human 
operators, and system interfaces is by timed and untimed 
Petri net modeling [Leveson and Stolzy, 1987]. The Petri net 
model successfully treats all aspects of the system as 
integral parts of the whole. 

This thesis will follow Hayward’s [1987] work, which 
employed Leveson’s untimed Petri net approach to system 
modeling. We will focus on the initial stages of the safety 
analysis, SA ci; potential “catast ropes failure 


determination and evaluation. Methodologies will be 


presented for untimed Petri net modeling of nontrivial system 
components and for uSing available automated techniques in 


preliminary safety analysis. 


Lite PEDTRE NED AND REACHABILITY 


A. INTRODUCTION TO PETRI NETS 

Petri nets were originally developed by A. W. Holt and 
others, based on the theories of Carl Adam Petri [Petri, 
1962]. Petri’s efforts were directed to presenting a theory 
for the asynchronous flow of communication between computer 
components. Holt demonstrated that Petri nets could be used 
to effectively model concurrent systems because they have the 
ability to model parallelism and synchronization. This 
thesis will assume the reader has little familiarity with 
Petri nets. An excellent source for more information can be 
found in Peterson [1981]. 

In computer science terminology, Petri nets are directed 
graphs whose nodes are transitions and places. Places model 
conditions, and transitions model the occurrence of events. 
The firing of a transition is considered to be inStantaneouwee 
therefore no two events can happen simultaneously. Inputs to 
a transition represent the preconditions of the event, while 
outputs of the transition are the postconditions. In Fuge 
3-1, the arcs of the graph (denoted by arrows) denote those 
Places (denoted by circles) which are inputs tome. 
transitions (denoted by bars) and those which are outputs. 
Fach place contains zero or more tokens, which represent the 


holding of a condition. The number of tokens contained in a 


pracem=s Called thesmarpking of Ehat placem{Peterson, 1981]. 
The marking or “state” of the entire net consists of the set 


of markings of all individual places within the net. 


Ore C#rO 


Figure 3-1. 





Figure 3-1 shows two basic arrangements of Petri net 
Perm eives. In Figure 3-1, arrows (arcs) coming out of the 
earecles (precondition places) and terminating into the 
vertical bars (transitions) represent the number of input 
tokens required to enable the transitions. The number of 
arcs coming out of the transitions signifies the number of 
tokens that will be created when the transitions occur. 
These newly created tokens will be deposited into the circles 
(postcondition places) where the arrows terminate. Note that 
there is no dependency between the number of input arcs 
required to enable a given transition and that transition’s 
number of output arcs. When a Petri net transition fires, 
the enabling tokens are consumed and the output tokens are 
created. 

A transition is “enabled” when there is a minimum of one 
token on each of its input arcs. Figure 3-2 shows the 


structures of Figure 3-1 with tokens in the input places. 


These are examples of enabled transitions because there is 
one token for each transition input arc. If there are less 
input tokens than there are input arcs to the transition, the 


transition 1s not enabled and cannot fire. 


O-=Q @-O 


Figure 3-2. 





Figure 3-3 depicts the basic structures from Figure 3-2 
after the transitions have fired. When a transition 


7 


“fires,” one token is placed in the output place(s) for each 
output arc. Notice that the input tokens have been consumed 


and output tokens created. 


ie t2 
PIoqure: g=32 Basic Petri N Me ne After 
+ ti Piri 


It is important to understand nondeterminism as it 
relates to untimed Petri nets. An enabled transition may fire 
instantly, at some later time, or never. Ina Situation such 
as Figure 3-4, either tl or t2 may fire, and either 


transition has equal probability of occurring on enews 


10 


Seecurring. Furthermore, if more than one transition in a 
given net is enabled, then any of the enabled transitions may 
be the next to fire. It is this feature that makes Petri 
Mets particularly suitable for concurrent system modeling 


[Peterson, 1981]. 


i 


Figure 3-4. 





Timed Petri nets remove much of the nondeterministic 
nature of the net by adding minimum and maximum allowable 
imeaiisiltion firing times. In the scope of our work in control 
and information flow modeling, only untimed nets were used. 
Modeling and automated safety analysis of timed nets is left 
FOr future research. 

Since Petri nets are used to model events and activities 
in a given system, they are particularly suited to model flow 


Se intormation or control. 


B. PETRI NET THEORY 

| The formal definition of Petri nets, using the notation 
of Peterson [1981], follows. A Petri net is composed of a 
See,ot places P, a set of transitions T, an input function I, 


SempouepuL function O, and an initial marking, Uo. 


ate 


DELinite ton. 


a) 
I 


Ky 
I 


Definition: 


Definition: 


Definition: 


# (eg, Lippi) 
Le te Re 


On es es te, See 


(oi, ee. 7 Pn! 


{Cj peor ° -, ty} 


Petri net structure, ®, is a 5-tuple 
C=(P,; 17 OC, toy 


is a finite set of places, n 2 O. 


is a finite set of transitions, mae 
The set of places and the set of 
transitions are disjoint, PNM T = null 


set, g@. 


is the input function, a mapping from 
transitions to bags of places. 


is the output function, a mapping ive@ 
transitions to bags of places. 


is the initial marking for the net 
where N is the set of nonnegative 
integers. 


A transition t4 can fire 1£ and emis geese 
it is enabled.An enabled transition may 
fire at any time or may never fire. 


The multiplicity of an @nput place = 
for a transition tj is the numbeise. 

occurrences of the place in the input 
bag of the transition, # (pipe liar 


transition ty is an input of place pies 
pi 2S an OUEpUE CE tege 


(Di, O (tz) ) 


transition ty is an output of place pi; if py 12S aneimeaeee 


lege: 


# (eg, 0 26pa)} 


Definition: 


(pa, Deatea) 


The state of the net, 6, conSiStS Glee. 
marking of all places within the net. 
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C. REACHABILITY 

The state of a system is defined by the set of conditions 
or markings that exist within the Petri net representation of 
the system at any given instant. Consequently, the state of 
a system is always well defined by the the set of states of 
individual places within the system. 

In fundamental terms, reachability is the possibility 
that a given initial condition (state) could lead to a given 
mimeal condition (state). If there is any possible state 
sequence from the initial state to the specified state, the 
specified state is said to be reachable from the initial 
State. A Petri net reachability graph is a directed 
graphical depiction of all possible state sequences beginning 
with the initial state of the net. In a reachability graph, 
nodes represent states and the root node is the initial 
State. Arcs between state nodes represent sets of transi- 
tions which, if fired, would take the net sequentially from 
one state to another. State reachability analysis is solely 
concerned with the possibility of any sequence of states 
(graph nodes) and transition firings (graph arcs) taking the 
system from a given initial state to a specified final state. 

Petri net safety analysis uses reachability to determine 
the possibility of mishap states. A Petri net reachability 
state set is the set of all states in the net reachability 


graph. This set can be further divided into two disjoint 


is 


subsets. One subset of states has the possibility of 
reaching either high- or low-risk states, while the other 
subset can reach only low-risk states. A critical state is 
a low-risk state which can either lead to a set of high-risk 
states or to a set of other low-risk states. If the final 
critical state on a path leading to a set of high-risk states 
follows the high-risk path, there is no further possibiiee 
of returning to the low-risk state set. If a reachable high- 
risk state exists, there must be a critical state somewhere 
on the state sequence path from the initial state to the 
high =—fisk state. [Leveson, 1986] 

One approach for the elimination of paths terminating in 
high-risk states is proposed by Leveson [1986]. This method 
begins with high-risk state determination and works backward 
along the state sequence to identify the first critical state 
encountered. Design techniques are then used to ensure that 
the high-risk path is never taken. This approach Mas 
appropriately named Backward Reachability Analysis. 

Our safety analysis work was primarily concerned with 
identifying mishap states of the system and determining their 
reachability from the. initial, states For a formal 
description of reachability theory see Peterson [1981] or 


Leveson [1986]. 
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Iv. PETRI. NET eee P=NUT 


A. INTRODUCTION TO P-NUT 

The Petri Net UTilities (P-NUT) were developed by the 
computer science department of the University of California, 
Irvine. The tools were constructed to assist researchers in 
applying Petri net analysis techniques to the design of 
complex concurrent systems. Our work employed P-NUT Version 
2.2 installed on a SUN 3 computer with an enhanced UNIX 
4.2BSD operating system. User manuals [Razouk, 1987; Morgan, 
1987] contain necessary installation information and provide 
guidelines for the translation of graphical Petri nets to P- 
NUT compatible input text files. 

P-NUT creates and manipulates three usable object types: 
Petri nets, reachability graphs, and execution traces 
Pmeazouk, 1987). Our work did not use execution traces and 
they will not be discussed further. 

Petri nets are input to P-NUT in a text format and 
transformed to an internal representation using the 


st Cie vaneay to01, The Reachability Graph Builder 


a 


(RGB)\ uses the translated file to build a reachability graph, 


4 


which can then be analyzed by the Reachability Graph Analyzer 
oS 


‘ 


(RGA) \ 
Our work consisted of creating an untimed Petri net text 


file, translating the file to RGA internal representation 


3 


form, constructing the reachability graph, and analyzing the 
reachable states. We will present only the necessary 
methodology, from Razouk {[{1987] and Morgan) (19387) 


accomplish these tasks. 


B. TRANSLATING THE PETRI NET 

The first step in creating a Petri net on P-NUT is to 
provide a textual version of the graphical net. The 
_translator tool (transl) is then used to transform )eaee 
textual net to suitable internal RGA format. Any text editor 
may be used for initial text file creation. The textual file 
consists of a net transition listing. Bach transit ome 
inputs (precondition places) and outputs (postconditaa@ 
places) are specified, one transition per line. To promote 
effective analysis, we highly recommend numbered transitions 
and meaningful place names. 

The text listing of each transition must begin with the 
transition number (or name) enclosed by colons, 1-.6€., "20 
The transition number is followed by a comma-separated list 
of input places required to enable the transition. If more 
than one token is required in any input place, the number is 
specified by enclosing it in parentheses following the input 
place name. Following the last input place of a transition, 
the symbol “->” signifies that the output places follies 
Output places are listed in the same manner as input places. 


As with input places, if more than one token will be gained 
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by an output place after the transition fires, the number 
must be specified in parentheses following that output place. 
Bolwvowinig cde lesemig of call transitions, the initial 
conditions, or marking, of the net must be specified. The 
initial conditions consist of a comma-separated list of 
places that contain tokens and are enclosed by “< >.” If any 
place initially contains more than one token, that number 
must be specified in parentheses as described above. 
Comments are allowed but must be indicated by enclosure 
within “/* */” | If any transition requires more than one 
line, the use of a reverse diagonal “\” followed by a 
carriage return is interpreted by P-NUT as a space character. 


An example of a simple Petri net is given in Figure 4-1. 


place-1 


a7 


rY_ 10 


place_2 place_3 


t] t3 
place_5S 


place_4 —1+() 
t2 


Figure 4-1. A Simple Petri N 


ay 


The P-NUT textual input file version of the EPagure se 


Petri net is contained in Figure 4-2, 


sC0: place 1(2) -> place 2) placcm 
stl: place 2,/placems a aoigeem. 
st2: place 4y = pracom. 

;t3: place S = ee hacoupm 


<place 1(2)> /* initial "conde lemcme. 





Figure 4-2. P=-NUT Text Version of Figure 4-j] Petri Net 


The net in Figure 4-1 contains four transitions and five 
places. The initial transition is numbered zero, reflecting 
the internal transition numbering sequence used within P-NUT. 
Note that transition t0Q is not enabled unless two tokens are 
contained in place 1, and that when transition €3 fires; @eme 
tokens will be gained by place 1. The initial condiltions@aw. 
two tokens in place 1. 


Assume this file is named “example 1.” pnl (P-NUT Pane 


S is a tool that scans the initial text file for syntactic and 


semantic errors prior to translation. The command to invoke 
pnl for example 1 is pnl example 1. The output Of “ieee 
tool will be a short error description. To translate the 


text file and redirect output to another file (rather than to 
the terminal) the command is transl example 1 > 


example l1.pn. If no input text file is specified, transl 
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will expect terminal entry. transl does not tolerate input 
errors, therefore exclusive use of input text files is 
recommended. The choice of output file name is at the 
discretion of the user, but we recommend the “.pn” suffix to 
denote that the file is in correct internal P-NUT Petri net 
format. Any P-NUT tool output can be redirected using the 


above method. 


C. BUILDING AND PRINTING REACHABILITY GRAPHS 
Reachability graph nodes represent states and the edges 
represent possible state transitions. The Reachability Graph 
Builder (RGB) takes a translated net text file as input and 
creates an internal representation of the Petri net 
reachability graph. In the untimed graph, the state of the 
system is completely described by the token distribution on 
places. Arcs in the reachability graph denote the path 


between source and destination states in the system. The 


file is rgb example l.pn > example 1.rg. Bie: “Seg” 
Suffix is recommended. If the Petri net is known to always 
have less than 127 tokens possible in any given place, it is 
called “bounded” at 127, and the command, rgb -b 
example 1l.pn > example 1.rg should be used. This option 
Saves both memory and processor time. If the net is known to 
be bounded at 1, it is called “safe” (not to be confused with 


ieee risk), and the command rgb -s example _l.pn > 


deo 


basic command to build the reachability graph of translated .“% 


example 1.rg will save even more CPU time and memery. 3Ue2 
of a file for redirected output is recommended for all 
commands, otherwise output will default to the standard 
output device. 

After building the reachability graph, it can be printed 
and viewed using the Reachability Graph Printer (RGP). The 
~ command rgp example 1.rg > example 1.g will prinewieese 
example graph and redirect output. The ‘“.g” suffix ie 
recommended for informational purposes and to differentiate 
the file from the internal format of the reachability graph. 
The important consideration in choosing suffix names for any 
P-NUT output file is uniformity. 

RGP output is a schematic of the reachability graph. 
Figure 4-3 is RGP output for the Figure 4-2 Petri net tee 


file. 


QO->1->2->3->0 


place (2) 


place 27 placem: 


place 4 
place i 





Figure 4-3. RGP Reachability Graph for Figure 4-1) 
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Mie ourem@4—5, MOticem@thnat the States are numbered from 
zero to three. The arcs signify which states are reachable 
from other states and describe all possible state sequences. 
The marked places comprising each numbered state are listed 
below the graph. 

Pbehough reachability graph printouts and state 
descriptions proved invaluable in the design and verification 
weeour Ssystem™ component modules, the value of the RGP 
diminished significantly as complexity and size of the Petri 
net grew. Our final model had more than 13,000 reachable 
states and resulted in an RGP output file of over 80,000 
lines. Such a large net waS impractical to analyze by 
inspection and required the use of the Reachability Graph 


Analyzer (RGA). 


D. REACHABILITY GRAPH ANALYZER (RGA) 

The RGA is a very powerful, interactive interpreter which 
allows dynamic identifier typing, recursion, and functions. 
The RGA enables model debugging and proofs of correctness 
through interactive analysis with the reachability graph. 
Through the RGA, the user gains access to place names, 
reachable states, and even the structure of the reachability 
graph. The RGA functions and capabilities discussed in this 
section are but a few of those found in Morgan [1987]. 

To invoke RGA, simply type rga <file.rg>. The entered 


file must be in P-NUT internal reachability graph format. 
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When the user enters an expression in RGA, the interpreter 
immediately evaluates it and returns the result. After 
evaluation, the interpreter discards the previous input and 
prompts the user for a new command. The prompt symbol is 
“>”. The user can also define expressions and functions for 
later use. 

There are three possible errors that can be encountered 
while using RGA: syntax errors, run-time errors, ame 
internal RGA errors. Syntax errors result in the message 
“command ignored” and a prompt. Run-time errors normally 
result in an appropriate message and a prompt. Internal RGA 
errors were never encountered in our work. 

RGA has a case-sensitive language. Command key words and 
predefined function names are always written in lower case, 
while user-defined identifiers may be written in lower, 
upper, or mixed case. All identifiers must begin with an 
alphabetic letter and can be followed by zero or more 
letters, underscores, digits, or periods. A number is one or 
more digits preceded by an optional minus sign and may be 
floating point as well as integer. 

The RGA interpreter normally recognizes the end of a 
command by the End Of Line character (EOL). If an expression 
or function definition is too long for a single line, scenes 
of a reverse diagonal character “\” followed by EOL is 


treated as a space character. Multiple spaces and tabs are 
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interpreted as a single space. Comments are Signified by 
Eaeeosure imo /*  */”, a.e., /* this is a comment */. 

Although the expressions and functions in RGA language 
are evaluated to many different types, our work used only 
integers, states, Booleans, and sets. If an identifier is 
assigned a value of any of these types, it will take on the 
appropriate type. 

The value of a place is evaluated as the integer number 
of tokens it contains in a specified state. To specify the 
State, the place identifier must be followed by a state- 
valued expression in parentheses. 

State constants are written as a number sign “#” followed 
by an integer. The first state in a reachability graph is 
denoted in RGA as #0. Places are referenced by the name 
given in the original input text file used for eventual 
reachability graph construction. Unnamed transitions are 
referenced by the dollar sign “S$”. The RGA standard is to 
reference the initial transition as the number “OQ” 
Mmiedmsitilon, Signified by $0. We found that naming places and 
numbering transitions (beginning with number zero) enhanced 
readability and ease of analysis with RGA. 

A state in the reachability graph consists of the 
markings of all places in that state and the sets of arcs to 
and from predecessor and successor states. The showstate 


function displays the marking of all places in a given state. 
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Only places that contain one or more tokens are considered to 
be marked. If a place is marked with more than one token, 
the number of tokens, enclosed in parentheses, follows the 
place name. 

The most powerful RGA language type we used was sets. 
Elements of an RGA set must be of the same type and are 
maintained and displayed by RGA in ascending numerical order. 
This display feature greatly aids readability and analysis. 
The predefined set variable used exclusively in our work was 
S, the set of all reachables net states. Set constants are 
written as a comma-separated list of states and are enclosed 
within curly braces, i.e e(#On#2s. 45). This example set 
consists of the initial state and the sequence of states two 
through five. If the set is empty, it will be displayed as 
an empty set of curly braces “{}”. 

The capability to construct and display subsets of the 
reachable state space proved invaluable in our research. The 
method for creating a subset is to specify the parent set 
followed by Boolean selection criteria. After expression 
evaluation, RGA will display all elements of the set meeting 
the Boolean criteria. Uncapitalized s is the predefined 
Subset variable of the set of all reachable states S. The 
syntax for creating and displaying a desired subset s of S 
which meets a specific Boolean requirement is {s in S | 


<boolean-expression>}. RGA will evaluate this expression 
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byecalculating and displayang all elements of the subset. To 
view the place marking of any state, Simply use the pre- 
defined function showstate (#<state>). 

Variable assignment can be used to store the value of a 
desired subset. The assignment operator is the colon 


A“ 


followed by an equal sign, :=”. Assignment allows the user 
to later recall the current value of the variable by simply 
typing the variable identifier following the RGA prompt. RGA 
will print the current value to the the standard output 
device. 

Available in-fix Boolean operators are standard 
arithmetic comparison tests: <, <=, =, >, >=, and <>. 


While the equal and not equal tests can be applied to any of 


the data types, the other operators apply only to integers, 


floating point, and strings. Boolean expression operators 
and and or are also included in RGA. The Boolean operator 
we used most frequently was exists, the existential 
qualifier. An example of the syntax of this operator is: 
exists <id> 5439 <set-expression> [<boolean- 
expression>]. RGA evaluates the expression by looping 


through each element of the set expression until it either 
evaluates an element as true and halts or checks all 
elements of the set and returns false. 

RGA contains several predefined functions. Two functions 


with substantial safety analysis value are succ(state) and 
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pred(state). succ(state) and pred(state) respectively 
return the sets of immediate successor and predecessor states 
for a specified state. RGA also supports user defined 
functions. Morgan [1987] contains an example user-defined 
function which successfully uses sucece to determine 
reachability of a given state from any other specified 
initial state reachable (initial-state, final-state). 
We altered the code of this function slightly by substituting 
pred(state) for succ(state) and produced a working 
backward reachability function. 

The RGA language is highly extensible through its support 
of user-defined functions and function libraries. lLibraieaes 
can be created as text files and entered by typing the file 


names following the reachability graph file name at RGA 


invocation. An example of an RGA invocation that will 
include two such libraries is: rga <file . roe 
<function libraryis <function library2>. RGA will 


accept the predefined user functions in these libraries and 
allow their use in the interactive analysis process. 
Although we did not use functions in our preliminary 
investigation, we highly recommend that their capabilities 


and usefulness be investigated in future research. 
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V. THE YSTEM NDER_ ANALYSI 


A. A SOFTWARE-CONTROLLED REAL-TIME SYSTEM 

The real-time system under analysis is a interrupted- 
explosive train safety-arming (SA) device for an air-to-air 
guided missile. The system was the first attempt by the 
Naval Weapons Center in China Lake, California, to replace a 
mechanical safe separation distance calculator with a 
microprocessor and software. The motivations for the 
conversion are the potential for greater accuracy, tremendous 
cost reduction, programmability, and the desire to apply 


state-of-the-art technology to fuzing design. 


B. SYSTEM BACKGROUND 

Hayward [1987] contains an excellent introduction to the 
system under analysis. The following discussion is a brief 
review of that introduction. 

A safety arming device is a precision system which 
incorporates mechanical, electronic, and explosive 
components. The purpose of the device is to arm the warhead 
See the correct time in tactical use and to prevent 
inadvertent high-explosive warhead detonation. The device 
must operate with high precision and be able to function cor- 
rectly for the logistic life cycle of the weapon. [McVay, 
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MIL-STD-1316C states that a safety arming device must 
independently prevent unintentional arming and provide forces 
to remove safety features originating from other 
environments. At least one of these features must depend on 
sensing the post-launch environment. The system must also 
provide an arming delay to ensure safe separation distance is 
achieved in all defined operational conditions. 

In mechanical SA devices, the system is locked in the 
safe position until unlocked by application of current to a 
solenoid. The device contains a setback weight, connected by 
the gears of an escapement mechanism to a rotor. The rotor 
contains the interrupt element. When the missile’s rocket 
motor fires, the acceleration boost drives the setback weight 
and causes the movement of the gears. The escapement 
mechanism serves as a pseudo-integrator to enable movement of 
the rotor from the interrupted (safe) position to armed after 
the missile has traveled a preset distance from the launch 
vehicle. Figure 5-1 shows the block diagram for a standard 
guided missile SA device [McVay, 1987]. The interruptors 
have mechanical and direct locking as required by M@i-Sa@e. 
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C. SYSTEM OPERATION 

Figure 5-2 is a system flowchart for the SA device under 
analysis. (Hayward, 1987] 

In Figure 5-3, we modified the original Hayward [1987] 
software flowchart by abstracting the hardware/software 
control port interface and removing the assembler code 
identifiers.The firing sequence in Figures 5-2 and 5-3 
Originates with the missile on an aircraft rack. An intent 
to launch (ITL) signal initiates a sequence which fires the 
thermal battery, charges the firing capacitor, powers the 
computer, and unlocks the SA device. The software then 
builds a preset safe separation distance lookup table for 


current distance comparisons. 


Ae 


Missile on R/C Rack 





A/C signaisintent to 
Launch (iTL) Firing Capacitor 
Charged 


ITL unlocks SA, 


Fires thermal battery, 
Powers Computer 


Rocket Motor Fires 


Launch 


4+ G Boost 


Software computes 
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SA Device Arms 


$A Locked in Arm 


Target Detection 


Detonation 


Figure 5-2. SA Device System Flowchart 


After missile launch, the software uses inputs from an 
analog to digital converter (ADC) and a timing loop to 


compute current separation distances from the launch vehicle. 
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A minimum 4G boost is required before the program will 
compare the calculated separation distance with the lookup 
table values. If the calculated value exceeds the current 
tabular value, the lookup table entry pointer is advanced to 
the next table value. The software then commands the 
solenoid to toggle, resulting in a ball lock mechanism 
rotating the interruptor by a one-third increment. Next, the 
software enters a delay loop to provide sufficient time for 
the solenoid to toggle. The program then loops back, updates 
the acceleration bias from the ADC output, and starts over. 
If the calculated value is less than the lookup table entry, 
the software delays, updates the calculated separation dis- 
tance, and conducts a second comparison. If the tabular 
distance is then exceeded, the solenoid is toggled as 
previously described.Three solenoid toggles are required to 
remove the interruptor. In addition, the warhead can not 
detonate unless the SA device is unlocked (which occurs after 


ITL is Signalled) and the firing capacitor is charged. 
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A. PROBLEMS IN SOFTWARE SYSTEM MODELING 

The major problem in software system modeling is that the 
model must be sufficiently accurate and detailed to provide 
meaningful safety analysis results. The model must 
incorporate the software flowchart, important environmental 
features, the nature of system components, and any initial 
conditions. Modeling should be a process of cooperation and 
continuous feedback between the designer and the modeler. 
Since the modeling process is difficult, nonessential details 
should be omitted. Phe hictichastettomciitte sdatticult to 
determine detail significance, the reduction of the system 
scope is important for minimizing required modeling time. If 
any system facet’s significance is unknown, it is best to 
incorporate it into the model. The system designer must 
provide feedback to the modeler to ensure a sufficiently 
accurate model. 

Hayward [1987] presented a methodology for building Petri 
net models of real-time, software-controlled systems. He 
provides detailed instructions for translation of software 
flowcharts to Petri nets and discusses a methodology for 
combining hardware and software system functions into a 


Single Petri net model. 


5 


While preparing the Hayward system model for automated 
analysis, we discovered several modeling flaws and corrected 


them. Our work reflects those improvements. 


B. A BOTTOM-UP APPROACH 

Our initial research plan was to familiarize ourselves 
with the the fuzing system, convert the Hayward [1987] model 
to entry text file, and conduct P-NUT aided automated safety 
analysis. Although the Hayward [1987] model was an excellent 
first attempt, serious shortcomings were soon discovered in 
the system component models. Following this discovery, we 
expanded our plan to include corrections to the Hayward 
model. 

After familiarization with the software and components of 
the safety arming device, we accepted the basic system 
framework and began at the module level of the Hayward model. 
We examined the functionality of the existing Petri net 
modules and compared this with our knowledge of actual 
component behaviors. This is not the method we recommend for 
conducting first-time modeling and analysis of a system. As 
stated in Hayward [1987], the initial modeling process should 
be a top-down approach, beginning with system and software 
flowcharts and interfaces, and abstracting out internal 
component functions. The final step prior to safety analysis 
should be component modeling and verification. Since we were 


given an essentially correct system framework, we began our 
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work from the bottom up. We redefined component interfaces, 
created the internal component Petri nets, and verified 
correctness with P-NUT. 


1% TL nsor M 


Wer charred sene intent Lo Laumeh (1TL) sensor first. 


The Hayward model is shown in Figure 6-1. 


el 


Off on 


eZ 


Figure 6-1. 





Figure 6-1 effectively models a two-state device, but 
an ITL sensor must do more than simply toggle. The sensor 
must have a means for outputting its current state. In the 
SA device under analysis, the software program checks the ITL 
sensor to determine which of two control flow paths to 
follow. The model in Figure 6-1 has no mechanism to allow 
NonDestructive ReadOut (NDRO) of its stored state and clearly 


needed this addition. 
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A component model must reflect system interface 
requirements and accurately represent behavior of the actual 
device. As an initial step, the modeler should analyze 
component functionality and document required system 
interfaces. He must then ensure that the model accurately 
represents all significant aspects of function and control 
flow. 

After adding NDRO capability to the ITL sensor, we 
realized that a proper model of a multifunction device 
requires a system lock. The lock ensures that once the 
component receives a command, it prevents new command 
processing until completion of the original input command. 
In the ITL sensor, this is critical. Without a system lock, 
NDRO could occur while the device was toggling and result in 
erroneous ITL indication. The diagram for the revised ITL 
sensor is shown in Figure 6-2. 

To increase readability and connectivity of the Petri 
net diagram, we recommend a standard input/output convention 
for all system modules. This convention is reflected in 
Figure 6-2 and consists of distinctly shaded input and output 


places. 
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In the complete system net, the contents of the 
modules should be abstracted. The modules are depicted as 
“black-boxes” with only interface places shown. This 


convention encourages regular component and system modeling. 
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Regularity is important due to the nontrivial nature of real- 
time systems. 

In large systems projects, modeling teams could be 
employed. In these projects, it is both appropriate and 
necessary to apply software engineering methods for module 
specification, namely clearly defined and consistent module 
interfaces. 

Beginning with the ITL sensor module in Figure 6-2, we 
adapted the electrical engineering wiring schematic 
convention to our modeling of intersecting Petri net arcs. 
Transitions t3, t4, t5, and t6 create and place tokens in the 
system-ready place. To conserve space and improve 
readability, we use intersections with nodes to denote common 
arcs between several transitions and a single place. It 1s 
important to note that this convention is inappropriate for 
representing arcs between multiple places and a single 
transition, as this would violate standard Petri net 
conventions. Additionally, the number of transition inputs 
and outputs must be readily apparent to an analyst without 
requiring a count of scattered intersecting lines. 

Creation of the ITL sensor in Figure 6-2 was a multi- 
step process. We began with the Hayward model of a two-state 
device and through a trial-and-error approach developed the 


model with NDRO capability. 
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The fundamental idea of a nondestructive read is to 
allow the sensor to output its state without changing that 
state. In Petri net terminology, the device must output state 
indication and simultaneously return to the marking held 
prior to the commanded read. Since no modeling of control or 
information flow is possible without token consumption and 
creation, the modeler must be innovative but should resist 
the temptation to build a baroque structure. The addition of 
places in a net can Significantly add to reachability state 
Space size and correspondingly increase analysis difficulty. 
(There are exceptions to this statement, such as in the use 
of interlocks, which actually restrict the reachable state 
space.) 

After creating the ITL sensor model, we converted the 
Petri net to a textual file, built a reachability graph of 
the system using P-NUT, and analyzed the reachable states by 
printing the graph. The textual Petri net for the ITL sensor 
model is shown in Figure 6-3. 

To reduce file size, we shortened most place 
descriptions. We follow this procedure throughout our work. 
In more complicated Petri nets, ten or more marked places per 
State are common, often filling several output lines for each 
state description. Modelers must be uniform selecting place 


name abbreviations. The pnl tool is extremely useful for 


SS, 


uncovering notational discrepancies and should be used prior 


to translating all text files to internal P-NUT format. 


ITL toggl revd,ITL snsr_rdy =>iTh togqgllendoua 

ITL_ NDRO inpt,ITL snsr rdy => 3rd) fiiesearcm 

ITL toggl_enabld,ITL -> no ITL,ITL snsr_rdy 

Ith coggimenabldy ne slii. -> ITL, ii snsr_rdy 

rd ITL status, ITL -> ITL_is true, (Tl, (Ubecnsmeuay 

rd ITL status,no ITL -> ITL is false,no ITL,1TL snsreray 


/* following code is for test looping purposes only */ 


st? : Glbvas true -—> Iietogg enews 
:t8: ITL is true -> ITL NDRO inpt 

:t9: ITL is false -> ITL toggl_revd 
:t10: ITL is false -> ITL NDRO inpt 
<1 | NDRO_ npe, no ITL, UG SnSr eaGy = 





Figure 6-3. Zextual JTL Sensor Petri ice 


To ensure all reachable states were identified, we 
added a looping structure at the end of the input text file. 
These added transitions simply feed the output back into all 
possible input places, ensuring all inputs and outputs are 
possible. This procedure is recommended for testing any 
module that has multiple inputs and outputs. The same effect 
could be achieved by creating a separate text file and 
reachability graph for each possible initial conditiem 
however Our approach accomplishes this with one text file and 
reachability graph.We translated the ITL sensor textual net 
using transl, built the reachability graph with the RGB, and 
used RGP to print it in readable form.This reachability graph 


is shown in Figure 6-4.The ITL sensor graph and state space 
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were sufficiently small to allow verification by hand tracing 


and inspection, thus the RGA was not used. 
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Figure 6-4. [TL Sensor Reachability Graph/State Space 


2. Analog to Digital Converter (ADC) Model 
The Hayward [1987] model for ADC, Solenoid, and 


Solenoid Control devices is shown in Figure 6-5. 
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Unfortunately the model in Figure 6-5 inadequately 
represents the actual devices. Our methodology for modeling 
the ADC follows. 

First, we analyzed the function of the ADC in our SA 
device. The ADC converts an analog input signal (from 
accelerometers) to a digital acceleration output. It should 
provide digital acceleration information when enabled and no 
output when disabled. The ADC has two interfaces with the 
overall SA system. It outputs digital acceleration values 
and provides feedback that it has been enabled or disabled. 

To represent control flow, we created a model that 
could be enabled or disabled and provide necessary feedback 
following command processing. Our approach was limited in 
that we did not attempt to model the information flow of the 
module. We assumed that if the ADC was enabled it would 
provide correct acceleration information, and if disabled it 
would not. This Significant assumption was made to reduce 
the scope of the model in view of time constraints. ie 
Should not adversely affect the credibility of the analysis. 
If the ADC malfunctioned and provided incorrect acceleration 
in excess of the actual value, the separation distance would 
be overestimated and could result in insufficient safe 
separation distance at detonation. This is an obvious result 
and there is little need to expend the extra effort and time 


required to model it. To ascertain correctness and 
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reliability of hardware components is not the goal in 
software system analysis. The safety analyst’s concern 
Smemla be for “qesign safety” or the effect off the 
component’s behavior within the context of the system 


environment. Figure 6-6 shows the refined ADC model. 
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In Figure 6-6, the system lock, ADC-Ready, reflects 
device inability to process simultaneous enable and disable 
commands. 

The ADC control structure iS more than a simple 
toggle. It must differentiate between enable and disable 
commands and allow redundant command processing. This was 
modeled by adding transitions t2 and t4. If redundant enable 


or disable commands are received, the model will not change 


States. It will, however, process the redundant command and 
signify that it has done so. This is analogous to a 
component with on and off switches. If the on switches 


pressed a second time, it does not cause the system to shut 
down. If a real-time system has multiple components which 
can enable or disable a critical component, it normally 
allows redundant enable/disable commands for insurance 
purposes. It iS our assumption that the ADC is such a 
device. If redundant commands were not allowed, this could 
eaSily be modeled by eliminating the redundant transition’s 
ability to deposit a token in the command-processed place. 
To accomplish this, simply remove the appropriate arcs. This 
would eliminate redundant command feedback. 

Following model creation, we again turned to P-NUT to 
verify correctness. We followed the same steps as in 
analysis of the ITL sensor and produced a printout of the 


reachability graph and state space. The textual file for the 
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ADC module is contained in Figure 6-7, while Figure 6-8 
depicts the resulting Petri net reachability graph. This was 
a small listing and analysis began with manual state 
examination. We examined all reachable states and validated 
the module. As a final check, we briefly analyzed the module 


with the RGA. 


tO: disable input, system ready -> disable cmd received 

Ree: enable anput, System ready -—> enable cmd received 

:t2: disable cmd received, system disabled -> system disabled, 
cmd_ processed 

:t3: enable cmd_received, system disabled -> system_enabled, 
cmd processed 

:t4: enable cmd_received, system_enabled -> system_enabled, 
cmd processed 

:t5: disable cmd received, system_enabled -> system disabled, 
cmd processed 

:t6: cmd processed -> output, system_ready 


/* the following code is for test loop purposes only */ 


fey: Output —> enable input 
eo Output —> disable input 


<disable input, system_enabled, system ready> 
/* initial markings */ 





Figure 6-7. Textual Version of ADC Petri Net 


Could this model be simultaneously disabled and 
enabled? We knew this to be impossible from our state 
inspection and verified it with the RGA. The translation of 
this question to RGA language is exists s in §S 


[ADC_enabld(s) = 1 and ADC disabld(s) = 1). 
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U=>i-—22->5.> 5-- 1-2 
{> 46g 9 - > 0 
| 
+= > 1 US ies 


disable input, system reddy, system eaaoled 
disable cmd received, Systenm enabled 
system | disabled, cmd _ processed 
system _ | ready,system | | disabled, output 
system __ _ready,enable_ input, system disabled 
disabterinput,sysocema ready, system | disabled 
enable cmd received, Sysremn disabled 
disable cmd received, system disabled 
cmd | processed, system | enabled 

- system ready,system enabled, output 

QO. system _ ready,enable_ input, system enabled 

1. enable cmd received, system enabled 





Figure 6-8. Reachability Graph for ADC Module 


The question is interpreted by RGA as: Is there any 
reachable state in which there is one token in the ADC 
enabled place and one token in the ADC disabled place? RGA 
response was false. We then asked the same question using a 


set variable assignment and assigned the variable name 


malfunctionl to this particular malfunction. The RGA Gneae 
for this questi Ones. malfuntionl := {s in S | 
ADC_enabld(s) = 1 and ADC disabld(s) = i RGA 
interpreted this as: Evaluate all elements of the set of 


reachable states in which both of listed places contain one 
token and assign this set to the variable malfunctionl. RGA 


responded with a set of empty curly braces, “{}”, signifying 
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that malfunctionl was currently of type set and had the value 
oe null. To redisplay the variable value later in the 
session, we entered the variable identifier, malfunctionl, 
and RGA again responded with the empty set. 

We then tested for system deadlocks: deadlocks := 
{s in S |nsucc(s) = 0}. nsucc(s) is a predefined integer 
expression that returns the number of successor states to a 
specified state s. The above expression is interpreted by 
RGA as: Assign to the variable deadlocks all elements of the 
subset of reachable states that have no possible successor 
states. The RGA responded with the empty or null set. 

3. Solenoid Model 

We next turned our attention to the problem of 
modeling the SA solenoid. The solenoid is a two-state device 
with enable/disable and NDRO capabilities. Two states refer 
to status left and status right. When the SA software 
determines the launched missile has achieved a proper 
increment of safe separation distance, it checks the solenoid 
Status (right or left) and commands the appropriate toggle. 
The solenoid toggles, causing the ball lock mechanism to drop 
ae ane move = ene fuze interruptor by a one-third 
increment. Following three toggles, the interruptor is 
removed. The solenoid system input commands consist of 
enable/disable, read, and toggle left/right. As in the ITL 


sensor and ADC, the system accepts only one command at a 
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time. If a second command is received prior to completion of 
the first, it is ignored 


Hayward [1987] modeled the solenoid by creating three 


separate modules: solenoid control, solenoid, and solenoid 
status toggler. These three independent Petri net models 
were intended to model a single system component. The 


solenoid control and solenoid modules were replicas of the 
two-state device in Figure 6-3. The solenoid control module 
modeled enable/disable functions and the solenoid module 
modeled the left/right toggle functions. The third module 
represented software status indication of the solenoid but 
toggled independently of the solenoid module. 

Since the SA device was never actually constructed, 
the software prototype required a method to simulate the 
toggle position. It accomplished this by toggling a status 
bit in a memory register. The Hayward solenoid status 
toggler is the model of this register function. 

We attempted to analyze safety of the completed 
software controlled SA device. Accordingly, we modeled the 
system with all designed software/hardware interfaces 
incorporated in a single full-function module. 

Creation of the solenoid model required several 
revisions and two weeks of intensive effort. The basic 
functions were defined and all interfaces specified. We then 


attempted to abstract another level of the device. Since the 
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solenoid performed three separate functions, we broke the 
Meojyect Luncteienally into NDRO, left/right toggle, and 
enable/disable capabilities. Rather than attempt module 
creation in one step, we combined the ADC “smart” toggle 
function and the ITL sensor’s NDRO capability as our first 


step. The resulting module is shown in Figure 6-9. 
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We then converted the the enable/disable toggle in 
Figure 6-9 to a left/right function and added another two- 
state module for enable/disable capability. We added a model 
feature which would disallow any accumulation of input place 
tokens. Token accumulation in the model could result from 
multiple input commands. Since Petri net transitions fire 
nondeterministically, these input commands might be handled 
out of order. The actual solenoid has no memory and can not 
respond to commands received while “in process”. In Petri 
net model terminology, the additional input tokens must be 
consumed. Figure 6-10 shows the final solenoid model.The 
solenoid model in Figure 6-10 has three fundamental operating 
States: ready (enabled), disabled, or in use. System =rcadge 
is the equivalent of the system ready places Gr em_aee 
sensor and ADC models in Figures 6-2 and 6-6. A token in 
this place indicates the solenoid is enabled (has power) and 
is ready to process input commands. A token in the 
solenoid in use place indicates that the Ssolen@ichea 
processing an input and will not accept further inputs until 
processing is complete. A marking of the system-disabled 


place represents power is off and no processing is possible. 
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The token accumulation problem described above is 
solved by the addition of token ConsUmpuetonmeeco—e If the 
solenoid in Figure 6-10 is in use, transitions tl3 Come 
ensure consumption of all incoming tokens without altering 
the command in process. If the solenoid is disabled, 
transitions t18 to t21 ensure that only an enable command 
will be processed. All other input tokens will be consumed 
and the system will remain disabled. 

After the solenoid token consumption scheme was 
incorporated, we did not “backfit” this feature to the ITL 
sensor and ADC Petri net models. This was solely due to time 
constraints. Our goal was to demonstrate procedure validity 
for preventing input token accumulation in any “no-input- 
memory” device. 

In Figure 6-10, no input transitions can fire unless 
there is an enabling token in the system ready place. ~Witen 
an input transition fires, this token is consumed and a token 
1s created and placed in the in usesplace: 

The method for returning the solenoid model to ready 
State after processing is shown in all the output firing 
transitions of Figure 6-10. Any transition Chat tipeswi ee 
place outside the module requires an input token from 
thein use place. When an output transition fires, a Eokenmene 


created and placed in the system ready place. 


DZ 


A major difference exists between the ADC 
enable/disable toggle in Figure 6-6 and the solenoid 
Meme/righnt toggle in Figure 6-10. The ADC must treat 
redundant enable/disable commands no differently than genuine 
toggles in terms of feedback to the system. (In the solenoid 
system-ready/disabled toggle, redundant commands are allowed 
and reflect this philosophy.) Redundant solenoid left/right 
toggles are not handled in the same manner. If the actual 
solenoid received a redundant toggle input and provided 
feedback, no toggle or resulting movement by the interruptor 
would occur, but system software would erroneously proceed as 
if these required events had taken place. For this reason, 
redundant solenoid toggle transition firings do not create a 
token in the toggled place. 

Following model creation, we converted the Petri net 
to textual form and input it into P-NUT. We translated the 
file, constructed the reachability graph, printed the 
graph/state space, and analyzed the graph on RGA. Although 
larger than the ADC and ITL sensor graphs, the solenoid 
reachable state listing and graph still permitted manual 
State inspection and graph tracing. The text file and 
reachability graph are contained in Appendices D and E. 

The final solenoid model in Figure 6-10 reflects a 
major change from our original module. The error was 


discovered during solenoid RGA analysis. We asked for the 


55 


set of system deadlock states (see Chapter VI) and were 
surprised when RGA responded with a two-state set. To 
enhance analysis and prevent deadlocks, we had added 
transitions to return output tokens back to any input place. 
One deadlock state had markings in left toggle recemvege 
toggle is left, and in_use, while the other deadlock Wasim 
equivalent redundant right toggle state. Redundant 
left/right toggle transitions, t2 and t4, originally had not 
required an enabling token from in_use or an output are upaes 
to system ready. This resulted in the model deadlockingmem 
the in_use condition whenever a redundant togqgleuiaa 
received. This was clearly not our intention. Although we 
wanted the solenoid model to withhold redundant toggle 
feedback, we never intended it to result in module deadlock. 
From a system view, this was equivalent to disabling the 
solenoid permanently. The correction was easily made and the 
final text input version is shown in Appendix D. Appendix E 
contains the resulting reachability graph printout and 
reachable state descriptions. 

We input the corrected model net to RGA. We again 
asked for the set of deadlocked states and RGA responded @waaa 
the null set. We then tested for possible accumulation of 
tokens. More than one token in a given place would signify 
that the model had failed to prevent command inputs while in 


use. We changed the input text file (Appendix D) initial 
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Somckietoncubyeadding a second token to the toggle left input 
Place. A new internal net was created and a reachability 
graph built. This procedure is required every time changes 
are made to the input text file. The new reachability graph 
was then analyzed on RGA. The input expression was 
excesstokens := {s in S | tokens(s) >= marked(s)}. 
The predefined RGA expression tokens(s) is evaluated as the 
integer number of total tokens present in a given state. 
marked(s) is evaluated as the integer number of places 
containing at least one token in a given state. If the 
number of tokens ever exceeds the number of marked places in 
any state, it indicates token accumulation in at least one 
Place. When RGA evaluates the expression, it returns the 
subset of reachable states which satisfy the specified 
Boolean condition. AS in previous examples, showstate(s) 
function is then used to display individual place markings 
within a given state. RGA evaluated our entered expression 
and returned a set of states in which only the 
toggle left input place contained more than one token. As 
Mimo WaS OUr initial condition, it validated our multiple 
input token prevention scheme. 

We returned to analysis of the model with single token 
initial markings and asked if it were possible to have the 
solenoid simultaneously ready and disabled, in use and 


disabled, or in use and ready. If these supposedly mutually 
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exclusive markings were possible it would represent a serious 
design flaw. We labeled this subset identifier as errorl. 
Since we had shown that there was never more than one token 
in any place, we were able to simplify our input expression. 
The RGA input for this question was: errorl := { s in §S | 
(system ready(s) + system disabled(s) > 1) or 
(in use(s) + system_disabled(s) > 1) or (in_use(s) + 
system_ready(s) > 1)}. RGA evaluated the expression and 
returned the null set. Since we had proven a maximum of one 
token in each marked place, arithmetically adding the place 
values in the first half of the Boolean expression was simply 
a shorthand expression for those states in which any were 
marked. If any of the places could have contained more than 
one token, this expression could not be used. The proper 
expression would then be errorl := {s in S§S | 
(system_ready(s) =1 and system _ disabled(s) =1) or 
(system_ready(s) =1 and in_use(s) =1) or (in_use(s) =1 
and system _disabled(s) =1)}. 

We performed a similar test for the erroneous state 
resulting from any two of the following places simultaneously 
marked: read enabled left toggle rece. 


right toggle received, system ready, system disabled. Ga 


expression was entered as error2 := {s in §S | 
read enabled(s) + left toggle received(s) ~ 
right _ toggle received(s) + system ready(s) ~ 
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system_disabled(s) > 1}. RGA again responded with the 
mie Set. 

TO prove that the module returned to a ready state 
following output, we asked RGA to return the set of all 
states in which any of the output status or toggled places 
was marked simultaneously with the in-use place. We named 
the subset identifier output_error. The RGA expression of 
=H1Ss question was output error ;= {s in § | 
(status_is_ left(s) + status is right(s) + 
toggled _output(s) + en dis output = 1) and (in_use(s) 
= 1)}. RGA evaluated the expression and returned the null 
set. This final check completed module correctness 
validation. To confirm our assessment, we hand-traced the 
reachability graph and examined all possible state sequences. 

4. The System Petri Net Model 

Following Solenoid testing, we refined the Hayward 
[1987] overall system model. 

The original Hayward model specified no requirement 
for missile release prior to the occurrence of a 4G boost. 
The attainment of this great an acceleration is impossible 
with the missile on the rack. The interlock between 
transitions tll and t12, in Figure 6-11, reflects the 
necessary sequence of rack release prior to the boost 


Securring. 
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Figure 6-11. Modeled 4+G Boost Interlock 


In a phone conversation with NWC China Lake, the 
fuzing system designer, Mr. Steve Rohde, specified a minimum 
4G acceleration boost aS a precondition to separation 
distance update calculation. This precondition prevents any 
toggling of the solenoid or interruptor movement without the 
required accelerative boost. This feature is modeled in our 
system Petri net (Appendix F) by making the 4+G boost 
occurred a required input place to the update separation 
distance transition, t59. 4+G boost occurred must be an 
output place of t59 to ensure accurate reflection that this 
precondition has been met in any subsequent separation 
updates. 

In Figure 6-12, ITL locks 1 and 2 and no-ITL Joes 
l1 and 2 were added after conversion of the net to P-NUT 
textual input form. While entering the net, we discovered 
that there was no current method to describe and maintain 
which of several paths was being taken on ADC entry and exit. 


In the system control flow, the ADC is enabled following a 
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B= ceoretibestacus. net uqumee 6-11, if ITL 1s true, control 
flow follows the left path, and if false, the right path is 
traversed. 

If ITL is true, the ADC is enabled, current 
acceleration is input to the software, and the ADC is 
disabled. After the ADC is disabled, control and information 
flow continue along the ITL path toward possible detonation. 

If ITL is false, the ADC is enabled, current 
acceleration bias is sent to the software, and the ADC is 
disabled. The control and information flow then updates the 
acceleration and loops back to recheck ITL status. 

Although there are four ADC instantiations in the net, 
the SA system contains only one physical device. The ADC is 
enabled/ disabled via one set of input places and feedback to 
the system is via a single set of output places. Since a 
Petri net is nondeterministic, there must be a modeling 
methodology to ensure correct path maintenance. The method 
we devised is to place system locks at module entry and exit 
points whenever there was a path choice. This lock 
guaranteed that only the correct transition would be enabled 
upon module output. Figure 6-12 shows the ADC portion of the 


final system net with path locks in place. 
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Since three solenoid toggles will result in removing 


the interruptor, we have used the model proposed in Peterson 
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[1981] to count the three required software commanded toggles 
(iteration counter). This counter models the system 
software trap and halts the program following the third 
software-commanded solenoid toggle. ine Paguce, 6-13, the 
presence of two tokens in the counter reflects first 
fmeeration completion prior to tranSition t79. Accordingly, 


this counter will enable t79 for only two firings. 
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Figure 6-13. Petri Net Model of a Counter 


There iS an aspect of the actual system that we 
intentionally omitted to reduce model scope and complexity. 
Actual system software enables the solenoid prior to, and 
disables it following, each read/toggle. We enable the 
solenoid initially and do not disable it on each iteration. 
This should not affect model validity, since we proved 
earlier that the disabled solenoid model could neither toggle 


HereOoutput status. 
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5. P-NUT Aided Safety Analysis of System Model 

We converted the graphical net to P-NUT text file 
format, translated it, built the reachability graph, and 
printed the reachability graph to an output file. The 
resulting RGP output contained over 13,000 states and 
required over five megabytes of memory storage. The sheer 
magnitude of the reachability graph precluded manual 
examination and forced total reliance on automated RGA 
analysis. The textual version of the system Petri net is 
Shown in Appendix G. 

Due to time constraints, we limited our RGA safety 


analysis to reachability of major hazardous and mishap 


states. 

To determine the possibility of missile detonation 
while attached to aircraft wing we entered: hazardl := { s 
in S | missl_on_rack(s) = 1 and detonation(s) = 1}. 


RGA responded with the null set, meaning it was not a 
reachable state of our model. 

To determine if detonation could occur when ITL was 
false, we entered the expression: hazard2 := { s in §S | 
no ITL(s) = 0 and detonation(s) = 1]. RGA responded 
en the null set. 

We next determined the possibility of detonation 


occurring without a minimum 4G boost. We entered hazard3 := 


62 


{ s in S | fourG bst_occrrd(s) = 0 and detonation(s) = 
1}, and RGA returned the null set. 

As a final question, we asked if detonation could 
occur if no power was routed to the computer. The expression 
hazard4 := { s in § | cmptr off(s) = 1 and 


detonation(s) = 1} also resulted in the null set. 
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VEL’: ESULT AND NCLUSION 


A. RESULTS 

This thesis has proposed a methodology for Petri net 
modeling and automated safety analysis of a real-time 
concurrent system. The sample system is a proposed air-to- 
air guided missile Safety and Arming (SA) device. The 
methodologies for initial modeling and safety analysis of 
this representative real-time system methodology were 
originally presented in Hayward [1987]. Our goal was to 
refine the modeling methodology presented by Hayward and to 
demonstrate the methodology for, and the feasibility of, 
automating the safety analysis. 

We introduced software safety, Petri nets, and 
reachability theory. We demonstrated steps required to use 
the Petri Net Utility Tools (P-NUT) and discussed the 
extensibility of the P-NUT Reachability Graph Analyzer (RGA). 
We next discussed P-NUT potential for automating detailed 
safety analysis. 

We have presented a methodology for system safety 
analysis using Petri net modeling. Using this methodology, 
we initially analyzed all aspects of system functionality and 
documented internal interfaces. We then abstracted the 
individual components and constructed Petri net component 


models based on a thorough study of their operation, control 
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flow, and system interfaces. We converted each Petri net 
model to textual form, entered it into P-NUT, and validated 
model design using P-NUT automated tools. After all system 
component models were verified, we examined the system Petri 
net, as presented in Hayward [1987]. After comparing the 
control flow of the net with our understanding of actual 
system operation, we discussed the basis for several 
refinements and demonstrated use of P-NUT to construct the 
reachability graph. Function and use of various RGA 
expressions and predefined functions for examination of 
hazardous state reachability were then presented. We 
concluded by demonstrating, from a preliminary standpoint, 


how to determine system safety. 


B. CONCLUSIONS 

As previously stated, our initial research goal was the 
automated analysis of a preexisting real-time system Petri 
net model. Unfortunately, the preexisting system model 
[Hayward 1987] was incomplete, requiring remodeling of 
components and refinement of the system Petri net structure. 
We essentially accepted the Hayward system framework and 
employed a bottom-up approach. We redesigned component 
interfaces and internals and verified correctness on the 
module scale prior to refining the system net structure and 


conducting automated safety analysis. 
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The recommended chronology for Petri net modeling and 
automated safety analysis follows. A brief summary is 
contained in Appendix H. 

Initially, the modeler/analyst should study system 
function and the designer’s description of possible mishap or 
hazardous states. He must then reduce the scope of the 
system to include only significant aspects and details 
pertinent to stated hazards. Although this is possibly the 
most difficult step in the entire process, it is critical to 
reducing scope and complexity of the resulting net. By the 
very nature of mishaps, it 1s extremely difficult to 
ascertain the relative import of individual components or 
processes. It is therefore imperative to incorporate any 
features of the system that may contribute to reaching 
hazardous or mishap states. If more model detail is desired 


after initial net construction, it is possible to refine the 


original Petri net. Continuous feedback from the system 
designer is critical to accurate modeling and safety 
analysis. 


The modeler must study system and software flowcharts 
thoroughly. He must document all software/hardware 
interfaces and incorporate the flowcharts into a single Petri 
net system description. Component internals should initially 
be abstracted with “black-box” descriptions and incorporate 


only required system interfaces. Multiple instantiations of 


66 


a component should be presented in the system net as separate 
“black-box” descriptions. 

After the framework is complete and approved by the 
designer, system component functionality should be studied 
and modeled. As in the system framework approach, one must 
incorporate only the desired aspects of component behavior 
and attempt to further divide the individual components into 
submodules, i.e., NDRO module, toggle modules, etc. An 
example of this second level of abstraction is found in our 
solenoid module (Appendix C). This Petri net model is 
basically a combination of three two-state devices with 
appropriate internal interfacing. 

As each component model is completed, P-NUT should be 
used to verify desired behavior. Proving component function 
and interface correctness on the module level permits easy 
and accurate incorporation into the system net. 

After completing the initial system model, P-NUT should 
be employed to construct the reachability graph. RGA 
automated safety analysis is then possible and can verify 
desired system behavior and safety. 

Manual construction of a 13,000-state reachability graph 
would be an arduous, lengthy, and error-prone process. P-NUT 
can construct this size graph on a Sun 2 computer in under 


two minutes of CPU time. 
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P-NUT is an extremely powerful suite of tools for Petri 
net analysis. One of the major drawbacks of the Petri net 
safety analysis methods cited in Leveson and Stolzy [1987] is 
the difficulty of constructing reachability 9Graphsmiieem 
complex concurrent-system Petri nets. The Reachability Graph 
Builder eliminates this problem, while the Reachability Graph 
Analyzer permits detailed analysis of the graph and reachable 
state space. The extensibility of the RGA language makes it 
extremely powerful and allows safety analysts to create and 
use predefined function libraries. We have shown how RGA 
quickly evaluates sensible and important safety questions. 
Answering these questions for complex reachability graphs 
would be extremely difficult, if not impossible, based on 
manual construction and analysis. 

While conducting our research, we came to fully 
appreciate the feasibility and suitability of Petri nets for 
software system modeling and safety analysis. In the course 
of modeling system components, Petri nets were versatile 
enough to enable accurate modeling of any system aspect 
desired. Petri nets captured every essential feature of 
system interface and control/information flow. Petri net 
modeling requirements for full specification of system inter- 
actions and dependencies forced us to explicitly state all 


control flow or behavior assumpt tomer Often, by merely 
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converting our ideas to a Petri net structure, we observed 
previously unnoticed assumption irregularities. 

Methodologies presented in Hayward [1987] and this thesis 
show that real-time system safety analysis is feasible using 
Petri nets and the automated P-NUT suite. We have endeavored 
to introduce the reader to these techniques and strongly 


encourage further research in the area. 


C. RECOMMENDATIONS 

We have attempted to demonstrate the feasibility of 
applying automated analysis tools to Petri net software 
System modeling and safety analysis. The methodologies 
presented are only a preliminary step in creating a complete 
methodology for successful and accurate real-time system 
Petri net modeling and automated safety analysis. 

We strongly recommend that the next refinement of these 
techniques incorporate timed Petri nets. The synchronization 
facets of real-time concurrent systems can only be modeled 
and analyzed completely if timing constraints are included. 
Leveson and Stolzy [1987] discuss the application of timed 
Petri nets to the modeling process. P-NUT contains tools 
Capable of construction and analysis of timed Petri net 
reachability graphs. [Razouk, 1987; Morgan, 1987] 

Leveson [1986] presents an algorithm for determination 
and elimination of Petri net critical states. A logical next 


step in automating software safety analysis is conversion of 
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this algorithm to RGA language. Translation should be 
possible, given RGA language extensibility. 

Leveson and Stolzy [1987] introduced the methodology of 
Simulating system faults within a Petri net model. The 
technique consists of adding fault transitions to cause 
unintended events or prevent occurrence of intended events. 
Automated safety analysis is particularly suitable for this 
technique as a new net reachability graph must be constructed 
for any Petri net change. Although this is a very difficult 
manual task, automation enables complex graph creation in 
several minutes. The analyst could quickly model and analyze 
a variety of specific component or software malfunctions. 
This would allow for more complete and accurate assessment of 
overall system safety. 

Gaining familiarity with P-NUT is a difficult proceae 
We strongly recommend the creation of an automated user 
interface. This interface might allow user construction and 
storage of a graphical Petri net via P-NUT. The software 
could use a graph-drawing capability with predefined place, 
transition, and arc components. It could then cue the user 
EGE suitable identifiers and interface with the Reachability 
Graph Builder and Reachability graph analyzer for translation 
of user reachability questions. With current user interface 
technology this capability seems reasonable. P-NUT is a very 


powerful and effective collection of Petri net analysis 
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meoolS. Rive Only eravoack EG large-scaie employment in 
further safety analysis research is the current awkwardness 


and difficulty of the user interface. 
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APPENDIX D 


NOID PETR El E 


toggle left, system ready -> left_toggle_received, in_use 

toggle right,system ready -> right_toggle received,in_use 

in use,left toggle received,toggle_is_ left ->toggle_is left, \ 
system ready 

Bighte Loggle received, toggle is left —> toggle is right, \ 
toggled 


mMiomuse, fight toggle received,loggle 1s right, toggled ->\ 


toggle is right, system_ready 
left toggle received,toggle is right -> toggle is left, \ 
toggled 
read status,system ready -> read enabled,in_use 
in_use,read_ enabled,toggle is left -> status is left, \ 
BOgglemuomlere, sVspcm ready 
in_use,read _enabled,toggle_is_ right -> status _is right, \ 
toggle is right, system ready 
Mmise seOgg beds EOggled OUEDUE,SySseem ready 
disable input,system ready -> system disabled,en dis TOuULPUE 
enable input, system ready -> system_ready 
enable input,system disabled -> system_ready,en dis output 
erable tinpur,i mn use —> in use 
Gdisable anput,in use —> in use 
Bogle rone,t use —> in use 
Boggle leche im ase —> in use 
read _status,in use -> in use 
disable _ ayejenbhe 5 system_ disabled -> System disabled 
read status, system disabled -> system disabled 
toggle _ left, system _ disabled -> system disabled 
toggle right,system_ disabled -> system disabled 


/* the following code is for test loop purposes only*/ 


mes 2° 
eZ: 
peZ4 : 
mEZ 
mez: 


mt 27: 
aie 6 ° 
2t29: 
me : 
ates 1: 


HESZ: 
ies S ° 
"t34: 


Status is left -> read status 
Statuses ett —> toggle left 
Status 1S left —> toggle right 
Status_is left -> enable input 
Status_is left -> disable input 


Status is right -> read status 
wees 1S Tight => teggle left 
status is right -> toggle right 
status_is right -> enable input 
Status 1S right —> Gasable anput 


toggled_output -> read status 


eoggled output -> toggle left 
Eeggledyoutput => toggle right 
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“tao. 
FE oi) = 


Teo 
*t38: 
7t39: 
“Tao: 
(tai: 


toggled output -> enable input 
toggled_output -> disable input 


en dis output 
en_dis_ output 
en_dis output 
en) dis ourreur 
ened Smouwepuc 


= 
a 
= 
2 
=—2 


read status 
toggle left 
toggle right 
enable yrnipur 
disable input 


<toggle left(1),toggle_is_ right (1),system_ready(1)> /*initial 
markings*/ 
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APPENDIX E 


Q0-—>1->2->3->8->13->20->22 


+=->26 
+->25 
+->0 

+->24 


ZO 30 
fae a= Zo 30 


+—->36->39->27 


+->6->11->15->21->27->31->37->38 
+=->7 


jp, oe! Se 
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(from #3) 


->6 (from #14) 


->18->22 (from #13) 


liao 


4+—+—-4+—-————— 


=—Pl6-222 


~J 


' 
Vv 
ro 


V 
un 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+-> 
| 
eo 
+ 
| 
+ 


Regge ler, System ready, toggle_ is _right 
left _toggle_ received, in use, eogg le (ise etait 
InRUSe, toggle is left, toggled 
System ready,toggle is lett, toggled sourpun 
System ready, toggle 1s vlete readvseaens 
EOgGgle Were, syseem. ready, toggle _ Als eae 
SySbemn ready,toggle | right, toggle _ tom ere 
System. ready, toggle _ 1S lee, enable _ input 
System_ ready, toggle_ is left,disable an pue 
in use, ogg leurs lett, read_ enabled 
left “toggle _ received,in use, toggle iste se 
eae use, renifo, ge neEoggtes received, toggle _ LS left 
system_ ready, toggle_ is left 
Gogg lewis ere re, system_ disabled, enud rs ICuGriNe 
system_ _ready, toggle_ is left, status | Ss) lene 
in use, ,toggle_ wee | rarointey , toggled 
toggle | chee thenger read | STaEUS, SYSECMGusooles 
toggle | Pere: toggle _ se Hebe, Sy Sect | disabled 
toggle _right, toggle _ ee Tee, system disabled 
EOggte Woeltefl, Syoeenu disabled, enable L aboerbte 
toggle _ is left,disable SI NpuUE, SVoeelhm disabled 
system ready, toggle is right, toggled output 
toggle is Vett,s/seemucwsaeted 
system ready, toggle ts leftr envdicgeueeus 
system | ready, toggle _ is militar, read_ status 
system _ ~ ready, toggle _xight, EKexsfeplhes is Raa gne 
SySEeme ready, toggle _ 1S oii enable | __ ALIGN STONE 
system_ _ ready, toggle_ is nighisy disable input 
in use, , toggle _ is _right, ,read enabled 
in use, right _toggle_ received, toggle is right 
system ready,toggle is right 
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moOgcgrew serait, System_ disabled,en dis output 
Sycreitm ready, toggle_ is Veigh, Status is ssesusiine 
mogguesrs raght, read | SEaeVeroysocem | disabled 
toggle _ Bicte, toggle is right,system disabled 
toggle _xight, toggle | PS een noystem disabled 
toggle _ is right, system_ dveapledeenable _2pput 
toggle _ is Pc rghiy disable input, system_ disabled 
toggle | is aight, system_ disabled 

Sy Seema. ready, toggle _ is Teich, en dis output 
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to detonote (t85) 


enoble 
solenoid 


OS nee 


received 


(tl? - t38) 





ox totenoid 


ROS en/ as 
ss output 
buitd 
tookup {39 
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lookup 
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316, 0) 


APPENDIX G 


YSTEM OKT 


aixrcrft -> rdy to fire therm_btry,awaitng_SA_unlck_cmd, \ 


awaitng_ Sag, tCeptire rekt emer, ia meoggl. Teva 


/* following is ITL sensor module, tl - t6 */ 


bel0: 
ell : 
me? : 
elas ¢ 
yi : 
eS ¢ 
wie 6 : 


Mined herevd, HibeonsEyray —> ITL toggl enabld 

(Mien RO 1npiaenn snsr cay -- Ed iIfL status 

mee _ toggl _ enabld,ITL -> no_ITL, HG) Snsr _rdy 

ITL mroggl enabld,no_ ITL -> Pity MASS sel 

1s6l INEG sere ye bias Ile -> (ee Se true, Dies snsr_ rdy, ITL 

ragitinstatus,no IT —> Ben ieces false, ITL snsr_rdy,no ITL, \ 
awaitng _emptr_ pwr 

awaitng SA_unlck_cmd,SA_lckd -> SA_unlckd 

awaitng sig to fire rckt_mtr -> awaitng_4G bst, \ 

awaitng rack _rel 

awaitng_cmptr_ pwr,cmptr_off -> cmptr_on 

avwadenigquEcdemarel,missl on rack —> missl _risd 

awaitng 4G bst,missl _rlsd -> fourG_bst_occrrd 

eva beng ekengecap ehgy—> frng cap chgd 

Ciper ON ws SEEWEe DEGEM Staxrtd 

Shewbe Progr Stased => TO reg initizd 

nGmGseg ina tl 7dy—ce nerd enabl Inpt 


/* following is Solenoid module, t17 _ t38 */ 


fe 7: 
aes : 
te hO ° 


mE : 
ez |: 


mie 2 2 ° 
mie 3: 


2t24: 
nel 5: 


mie © 2 
eg 


ae: 


POoggueltt er mpt,solmord rdy —> lft toggl revd,solnoid in use 
toggl_ Et Inptjseimomdsrdy => rt _toggl_ rcvd,solnoid in use 
ee Btoggl neva, veoggiuis. lie, solneid in use -> toggl | ates apse \ 
solnoid rdy 
PameOTgwerevd, coggiers Itt —> toggl is rt,solnoid toggld 
Poameoddmerevd, Logg 1s 1t,solnoid in use —> toggl is rt,;\ 
solnoid rdy 
Deemeojgj lerevad, FOggrais tt —> toggl is Tft,solnoid toggld 
solnoid_ NDRO_inpt,solnoid_rdy -> solnoid_rd_enabld, \ 
solnordsin use 
solnoid_ rd _enabld,toggl_is 1lft,solnoid_in_use -> \ 
Status is lft, \ 
Hogg sls Tite, solnoid rdy 
solnoid rd _enabld,toggl_is rt,solnoid_in_ use -> \ 
Sisal Ste Siete 7 
Eoggiesvrt,solnoid rdy 
solnoid toggld,solnoid in use -> \ 
solnoid toggld_outpt,solnoid_ rdy 
solnoid disabl_inpt,solnoid_rdy -> solnoid_disabld, \ 
solnoid en dis outpt 
Solnoidenablvinpt,solnoid ray —> \ 
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>t29: 


solnoid_rdy,solnoid_en dis outpt 
solnoid enabl_inpt,solnoid_disabld -> solnoid rdy, \ 
solnoid ‘én dilsrourse 


/* following transitions, t30 - t34, consume incoming tokens while 


a7, 


/* solenoid is in use. this prevents accumulation at the input 
places */ 


et 30s 
fes 
[ESZ: 
‘E33! 
st oa: 


solnoid_ disabl_ inpt,solnoid_in_use -> solnoid_in use 
solnoid enabl_inpt,solnoid _in_use -> solnoid_in_ use 
Loggia rt _inpt, solneidmin wee => solnoid_in_use 
toggl lft _inpt,solnoid_in_ use -> solnoid_in use 
solnoid NDRO_inpt, solnoid_ in_use -> solnoid_ in_use 


/* following transitions, t35 -t38, consume incoming tokens while 


“ts 


/* solenoid is disabled */ 


IC oiole 


“EoG: 
a Boe ee 
-rsoe 


solnoid disabl_ inpt,solnoid_disabld -> solnoid_disabld, \ 
solnoid_en dis outpt 

solnoid NDRO inpt,solnoid disabld -> solnoid _disabld 

EOgg l= uae EInpt, so ljores disabld -> solnoid | disabld 

toggl_ rt inpt, solnoid disabld -> solnoid disabld 


Solnoid envy dis outpe =>) lkup seo ioe 
tkup tbl bit => ptr lent an Elza 


> ptr _cnt_initizd —> awaitng TIE stavucmencr 


awaitng_ ITL status check —271Ti NDROginpE 
eS _true- -> ADC _ enabl inpt, TDi lock_ iL 
cv San false -> ADC | enabl Jingle, nom oe aie lock_ | 


/* following transitions, t45 - t51l, are contained in ADC module */ 


“£455 
-t46: 
7t47: 
‘eas 
*t49: 
Sou: 
site las 


fe SZs 
SE S/O 
7t54: 
He ee 2 
RE io) = 
ny eo ae 
eS 
a eee po 


te): 
Stow: 


ADC disabl inpt, ADC rdy -—> AD€idisabievevd 

ADC enabl_ inpt,ADC _xrdy -> ADC enabl_ rcvd 

ADC disabl rcvd,ADC disabld -> ADC disabld,ADC cmd procssd 
ADC enabl_rcevd,ADC disabld -> ADC enabld,ADC cmd _procssd 
ADC _enabl_ rcvd,ADC_enabld -> ADC_enabld,ADC cmd _procssd 
ADC _disabl rcvd,ADC enablid -> ADC disabld,ADC_cmd_procssd 
ADC cmd procssd —> ADC outpt, AvGrray 


ADC outpt, ITLL lock 1 => accel linperd 

ADC outpt,no ITL lock_1 -> accel _ bias inpttd 

accel inpttd => ADC disabl inpe,.romtoc aa 

accel _bias Ealigheinige: -> ADC _ disabl _inpt, Non nugoe Lock a2 

ADC Mourpe, NO Troe ock 2 => awaitng ITL_ status _ chck 

ADC outpt,ITL lock _2 -> awaitng vel updat 

awaitng vel _updat -> awaitng_sep dist_updat 

awaitng sep dist_updat,fourG bst_occrrd -> sep dist_updatd, \ 
fourG ibst vecerue 

sep dist updatd =>" rend begg! dase 

sep dist updatd -> not _rchd toggl dist 
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neo” - 
mte6 3S 
7E64: 
Be 6 © : 
“too: 
a6 7 ° 
PEoo: 
7to9: 
ear) ° 
aiey i: 
wey 2: 
eS : 
st 74: 
med O° 
PE70: 
2 at a i 
‘t78: 
ie 7 se 
to 0: 
eo 
wEo2 : 
‘EOS: 


BeohiGmeOg ladiStm—2peb cnt  snermntd 
NOewEChC FOGG! sdtst, —- dwaltng tmr Strt 

ptr _cnt_incrmntd -> solnoid NDRO inpt,await_timr_delay 
awaitng tmr_strt -> tmr_running 

tmr_running -> awaitng_elpsd_time_chck 

awaitng _elpsd_ time _chck -> tmr_running 

awaitng elpsd time chck -> tmr_ wait ovr 

Stauus 1S LEG —> toggl_ ae pee 

status | aoe rt -> TOOG ls ieee panpt 

eg wait _ovr -> sep_ dist chckd 

sep | . dist _chckd ==> jcalerel Broggd. dist 

sep dist ~chekd -> ITL is true 

solnoid toggld_outpt -> ball_lck_toggld 

ball lck toggld -> ball_ rlsd 

ball rlsd -> one third_ incrs of intrptor 

await timr delay -> rdy for _wait200 

rdy for wait200 -> awaitng_sep dist _chck 

awaitng__ Sep_ dist chck,iter counter -> ITL is true 
one third _incrs of _intrptor (3), SA_unlckd -> missl_armd 
missl_ armd -> missl_ eka Viner 

missl_ Beokannearm, sasc detcts mtgt => idet sig revd 
frng cap chgd,det sig rcvd -> detonation 


/* initial markings follow * / 


meecmem:),oA lekd(i),;missl on_rack(1),cmptr_ off(1),no_ITL(1),1ITL_ 
snsr_rdy(1),\ 

eogglas rt(1),solnoid rdy(1),ADC rdy(1),ADC.disabld(1),\ 
Store detcts tgt(1),iter counter(2) > 
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APPENDIX H 


SUMMARY OF MODELING AND ANALYSIS METHODOLOGY 


The recommended chronology and methodology for Petri net 


modeling and automated safety analysis of a software- 


controlled real-time system follows. 


sy 


Study system functions. Have the designer explicitly 
identify all perceived hazardous conditions. 


Study system and software flowcharts thoroughly. 
Attempt to reduce system scope to include only 
Significant aspects pertinent to the stated hazards. If 
in doubt as to significance of any detail, include it. 


Document system interfaces. Incorporate all flowcharts 
into a single Petri net system description. Abstract 
component internal functions by including only ~DBigere 
box” component descriptions with external system 
interfaces. To increase readability, multiple component 
instantiations should be represented as separate “black- 
box” descriptions. 


Once the initial Petri net system framework is complete, 
obtain verification from the designer. Study and model 
component functionality with Petri nets. As in system 
framework approach, incorporate only significant 
aspects. Attempt a second level of abstraction by 
further division of components into submodules and 
internal interfaces. 


Following completion of individual component Petri net 
models, convert the nets to textual form. Any text 
editor can be used. Chapter VI gives detailed 
instructions for the conversion process. 


Translate the component text file to internal Petri Net 
UTilities (P-NUT) format. Redirect output to a second 
file for later use. The appropriate translation command 
is transl <filel> > <filel.pn>. The .pn suffix 
identifies the file as an internal Petri net 
representation. 
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AE 


Build the reachability graph from the translated Petri 
net file using the Reachability Graph Builder (RGB) and 
Bedirect output The proper command is rgb _ {-bs] 
<filel.pn> > <filel.rg>. The optional suffix b 
Signals that the net is bounded at 127, while the s 
suffix signals that the net is safe, or bounded at 1. 
The .rg suffix denotes the file being in internal P-NUT 
reachability graph form. Note that the input file must 
be in internal P-NUT format. 


The component’s reachability graph can be printed in 
readable form using the Reachability Graph Printer 
(RGP). Redirect output to a new file. The proper 
command is rgp <filel.rg> > <filel.g>. The .g 
suffix is a recommendation only. 


Study the reachability graphs and state spaces of each 
component. Verify that functionality has been 
accurately modeled. 


If the component is complex and has a large reachability 
graph, use the Reachability Graph Analyzer to assist in 
the analysis. The command to invoke RGA is rga 
<filel.rg> [function libraries]. Notice that user- 
defined function libraries may be invoked and used with 
RGA. The input file to RGA must be in internal P-NUT 
reachability graph format. Chapter VI gives several 
detailed examples of analysis expression syntax for the 
RGA language. 


After validating component models, incorporate them into 
a textual file version of the overall net. Repeat steps 
6 through 10 for the system model. The final 
reachability graph may contain several thousand states 
necessitating analysis solely with the RGA. Translation 
of safety analysis questions to RGA net terminology and 
Syntax is discussed in Chapter VI. 
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